Repository navigation
Build and test conda-recipe-cf for Intel Python CI - #204
jharlow-intel wants to merge 2 commits into
Conversation
Adds what Intel Python CI (gh-ci) needs from this repository: ci/ with the shared matrix, build and test-hook scripts, ci/test.py and ci/config.yml, and .github/workflows/intel-ci.yml, which builds conda-recipe-cf for every platform and Python version the recipe declares and tests each package in a clean conda-forge environment, as Jenkins later does. conda-recipe-cf/conda_build_config.yaml now declares the Python versions conda-package-cf.yml builds, for ci/matrix.py, and NumPy 2: without a numpy variant conda-build falls back to NumPy 1.26, which has no builds for Python 3.13 and newer. conda-package-cf.yml passes --python and --numpy itself, so it is unaffected.
|
|
||
| concurrency: | ||
| group: intel-ci-${{ github.ref }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
With cancel-in-progress: true keyed on github.ref, two quick merges cancel the first commit's whole run. Jenkins, which waits for that run, gets no packages for it.
| cancel-in-progress: true | |
| cancel-in-progress: ${{ github.event_name == 'pull_request' }} |
| numpy: | ||
| - '2' |
| @@ -1,3 +1,16 @@ | |||
| # The Python versions to build, one per line and without selectors: ci/matrix.py | |||
| # reads them for .github/workflows/intel-ci.yml. NumPy 2, as in conda-forge's | |||
| # global pinning; conda-package-cf.yml passes its own with --python and --numpy. | |||
| "--artifacts", required=True, type=Path, help="the downloaded artifact" | ||
| ) | ||
| parser.add_argument( | ||
| "--work", required=True, type=Path, help="an empty scratch directory" |
There was a problem hiding this comment.
hooks.py doesn't check that --work is empty, and may install conda-index into the user's base environment.
|
|
||
| - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0 | ||
| with: | ||
| python-version: "3.12" |
There was a problem hiding this comment.
Is there any issue to use the newer python?
| activate-environment: "" | ||
| conda-remove-defaults: "true" | ||
|
|
||
| - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0 |
There was a problem hiding this comment.
Alternatively we can drop setup-python and run with shell: bash -el {0} with base activated.
bash is available on Windows runners too, and setup-miniconda supports this shell there. The step bodies become plain python ci/build.py … and python ci/hooks.py …. The $CONDA path code and hooks.py's re-run of itself would then only matter for local use.
| @@ -0,0 +1,135 @@ | |||
| # Intel Python CI (gh-ci) for mkl_random: builds the conda-forge recipe, conda-recipe-cf, for every | |||
There was a problem hiding this comment.
The same PR is open in three repos at once.
Have you considered moving common things (scripts, workflow) to some common repo like https://github.com/IntelPython/devops-tools ?
That would help to reduce the duplication.
Description
Adds what Intel Python CI (gh-ci) needs from mkl_random: a
ci/directory and a new workflow,.github/workflows/intel-ci.yml. The workflow buildsconda-recipe-cffor every platform and Python version the recipe declares, and tests each package in a clean conda-forge environment withci/test.py. Intel's Jenkins then waits for that run, tests each package again on its own machines, scans it, and for a release tag publishes the packages it tested. Jenkins isn't switched on for mkl_random yet, so until it is, this only adds a GitHub Actions workflow.ci/matrix.py,ci/build.py,ci/hooks.py: the shared gh-ci scripts, standard library only. Here they look forconda-recipe-cf/first and build Linux and Windows on GitHub-hosted runners.hooks.pyinstalls the test requirements fromci/config.yml, the way Jenkins does.ci/test.py: runspytest --pyargs mkl_randomagainst the installed package and writes a JUnit report.ci/config.yml: the workflow, the artifact names (mkl_random {platform} Python {python}, asconda-package-cf.ymlnames them) and the test requirements,pytest.conda-recipe-cf/conda_build_config.yaml: now lists the Python versions, the onesconda-package-cf.ymlbuilds today, forci/matrix.py, andnumpy: '2'. Without a NumPy variant, conda-build falls back to NumPy 1.26, which has no builds for Python 3.13 and newer.conda-package-cf.ymlpasses--pythonand--numpyitself, so it is unaffected.ci/README.mdand AGENTS.md notes.A pull request builds the two newest regular Python versions on Linux and Windows; pushes to
masterand tags build them all.Miniforge is pinned to 26.7.2-0. Miniforge 26.9.4-0, released on 22 October, makes
setup-miniconda'sconda initfail on Windows runners, and the existingconda-package*.ymlworkflows, which installlatest, hit it too on this pull request.Overlap with #202. It also sets
numpy: '2'inconda_build_config.yamland drops Python 3.10, so whichever lands second needs a small rebase, and if 3.10 goes it should leave thepython:list here too.conda-package-cf.ymlandintel-ci.ymlnow both buildconda-recipe-cf; retiring one can be a follow-up.Verification
ci/test.pyagainst each package: 380 passed on Linux 3.14 and on Windows 3.15.pre-commit runon every changed file, all hooks passing, andzizmoronintel-ci.yml, no findings.python ci/matrix.pylists 14 builds, Linux and Windows for 3.10 to 3.15 and 3.14t; with--event pull_requestit lists 3.14 and 3.15 on both.ci/config.ymlloads with gh-ci's own parser.Not verified